1. Field of the Invention
Generally, the present invention relates to the telecommunications and digital networking. More specifically, the present invention relates to the classification of packets in a heterogeneous data redirection networking device.
2. Description of the Related Art
In the realm of digital networking and telecommunications, data is often assembled and then transmitted and received in certain discrete units known as packets. All or a specified number of the packets originating from the same source device, connection or application can be grouped together in a “flow.” Though the term “packets” is used in this discussion, “packets” may also refer to other discrete data units such as frames and so on. Network devices (e.g. switches, routers, etc.) that intercept and forward such flows or packets are often configured with a plurality of ingress ports (i.e., into which input flows arrive at the device) and a plurality of egress ports (i.e., from which input flows are routed outside the device). In this regard, and for purposes of the present invention, ports may be physical, logical or a combination of physical and logical. Further, ports may be bidirectional in nature such that they may serve as both ingress ports and egress ports. When an input flow or single input packet is received by a network device it could have be destined for output over just a single egress port or more than one egress port. An input flow/packet with just a single destination egress port is referred to as unicast, while a flow/packet that is destined for multiple egress ports is referred to as multicast.
Certain network devices may be classified as heterogeneous in that they may accept data (e.g., via ingress ports) of many different types and forward such data (e.g., via egress ports) in many different formats or over different types of transmission mechanisms. Examples of such devices include translating gateways that unpack data in one format and repackage it in yet another format. For purposes of the present invention, a heterogeneous network is considered the general case for those non-heterogeneous networks (i.e., those networks that accept and forward only one type of data over one type of transmission mechanism); as such, these non-heterogeneous networks are meant to be within the scope of this invention. When a two-port non-heterogeneous device merely forwards data from its one ingress port to its one egress port, there is less of a need to classify the packets. However, in devices where there are multiple types of ports (e.g., ingress, egress, ingress/egress combination, varying data formats, varying physical connections, etc.) and, where the physical ports may be combined or section into one or many logical ports, there is a critical need for packet classification.
FIG. 1 illustrates a heterogeneous network environment that provides for different types of data formats and marries different transport mechanisms. As will be evident to those skilled in the art, many different combinations of such formats and transport mechanisms (as well as many others) can be combined to form such a network environment. A network ring 100 may, for example, include a high capacity network such as a SONET ring and usually provides service to more than one customer. Such customers may further distribute the service(s) they receive via the network ring 100 to one or more nodes behind their own internal network. FIG. 1 shows nodes 110, 120, 130, 140, 150, 160 and 170. Nodes 140 and 150 are access the network ring 100 via the same. Customer Premises Equipment (CPE) 145. Similarly nodes 130 and 170 access the network via CPE 135. The remaining nodes directly access the network ring 100. CPE 145 and 135 may, for example, be gateways that apportion transport mechanisms such as Ethernet or PDH (e.g., T1 lines, T3 lines, etc.) over the network ring 100, making use of the bandwidth given thereby. As mentioned above, network ring 100 can be a carrier-class network that may have a very large bandwidth, for example, such as 2.5 Gigabits per second (Gb/s).
Therefore, network ring 100 is generally not like a typical Local Area Network (LAN) service or a typical point-to-point leased line service. Recent efforts, however, have sought to provide both of these types of services in an environment such as that shown in FIG. 1. The first, called “Private Line Service” or “Ethernet Private Wire Service,” for example, is an attempt to create a secure and dedicated leased line type of mechanism. For instance, assume a dedicated connection-oriented service was desired between node 130 and node 110, which belong to the same organization B, yet might be separated by a long physical distance. A Private Line Service could be used to provide the node 130 to node 110 services. Private Line Service would create a point-to-point, dedicated interconnect between node 110 and node 130 even though both are segregated over the network ring 100.
Yet another service, known, for example, as a Transparent LAN or Ethernet Private LAN Service, is an attempt to create a virtual Local Area Network (LAN) out of those nodes that belong to the same customer. For instance, if nodes 120, 140, 150 and 170 (i.e., all belonging to the same customer organization A) were part of a virtual LAN using the network ring 100, they would appear to one other as being on the same customer A LAN, even though node 120 might be separated a great distance from nodes 140, 150 and 170. Further, the nodes would appear on the same LAN even though all four nodes might be operating under different transport mechanisms (e.g., if Transparent LAN services were enabled). Likewise, another Transparent LAN service could enable nodes 110, 130 and 160, which all belonging to customer organization B, to appear to be on B's LAN.
Yet another challenge of provisioning such services over network ring 100 is from the standpoint of the CPEs, such as CPE 135 and CPE 145. The CPE must consider provisioning the services so that the nodes (e.g., end client or users) can accurately be identified according to their network flows and be distinguished from one another. Since the actual network is not precisely connection-oriented, the CPEs should be capable of distinguishing data units belonging to organization A from those belonging to organization B. Further, where both Private Line and Transparent LAN services are be present and both seek to be provisioned on the same CPE, such services should be distinguished by the CPE. When a CPE also has the task of allocating its resources, scheduling and routing data units, determining egress ports and so on, packet classification becomes much more difficult. Further, where a CPE might support the provisioning of T1 lines to one node and Gigabit Ethernet or 10/100 Ethernet to another node, the CPE must be able to classify and distinguish among such packet types internally.
While CPEs 135 and 145 could simply be built with many different physical ports and large memories, such a CPE is cost-inefficient to the customer. Further, such a CPE does not scale well where the customer desires many different channels or logical ports over the same physical ingress or egress port. Recently, there are efforts underway to provide scalable CPEs that can operate on less hardware and thus, with less cost and complexity than their predecessors, but while still providing better performance than their predecessors. However, in such efforts, classification of data becomes important as functions such as prioritizing and scheduling data units and allocating limited CPE physical resources (e.g., memory and processing cycles) come to the fore. Further, where logical and physical ports are bidirectional in nature, having both egress and ingress capability, scheduling and allocating become vital to the proper operation of the network.
Thus, what is needed is a networking device with a data classifier that can cheaply and efficiently be used for managing, queuing, processing, scheduling and routing data units between multiple ingress/egress ports and between varying transmission media and transmission formats.